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I.  The  Field  Concept 

A.  Introduction 

This  report  describes  a  portion  of  the  STAR  (Simulation  of  Tactical 
Alternative  Responses)  combined  arms  ground/air  combat  simulation  model. 

STAR  has  been  developed  by  students  and  faculty  of  the  Operations  Research 
Department  at  the  Naval  Postgraduate  School  as  a  tool  for  investigating 
ground/air  combat.  The  model  is  programmed  in  SIMSCRIPT  II. 5,  and  a  knowledge 
of  that  language  is  presumed  in  this  report.  Documentation  of  various  other 
aspects  of  the  model  is  given  in  references  [1]  -  [5]. 

The  purpose  of  the  present  report  is  to  describe  the  Field  Module 
of  STAR.  The  Field  Module  is  responsible  for  simulating  vehicles  encounter¬ 
ing  minefields  and  other  similar  battlefield  features.  The  remainder  of  this 
chapter  will  introduce  the  general  concept  of  a  field  and  the  two  types  of 
actions  related  to  fields.  Chapter  II  will  describe  the  data  structures 
representing  fields  and  the  basic  subroutines  for  creating  fields  and  monitor¬ 
ing  vehicle  location  with  respect  fo  fields.  Chapter  III  will  discuss  the 
modifications  required  in  the  existing  STAR  model  to  incorporate  the  Field 
Module.  Finally,  Chapter  IV  will  consider  the  actions  -  the  tactical  responses 
that  occur  as  a  result  of  fields. 

B.  Fields 

Definition:  A  field  is  an  area  on  the  battlefield  which  influences 
battle  actions  and  hence  battle  outcome. 

Examples  of  fields  include  the  following  sorts  of  areas  on  the  battlefield  - 
some  manmade  and  others  naturally  occurring: 


Minefields  -  dug  in  or  scatterable 

Engineered  or  natural  obstacles 

River  crossings 

Bridges 

Towns 

Forests 

Artillery  trigger  areas 

Residual  nuclear  or  chemical  effects  areas. 

Forests  are  currently  handled  separately  in  the  LOS  module  L  .  The 

Field  Module  will  be  set  up  to  be  able  to  handle  the  remaining  fields. 

Fields  are  represented  in  the  STAR  model  as  geometric  areas 
overlaid  on  the  terrain.  The  field  module  has  the  following  functions: 

1.  For  each  element  in  the  simulation,  monitor  when  the  element 
enters/exits  each  field. 

2.  When  an  element  enters  a  field,  perform  designated  actions 
(e.g.  lower  mine  plow,  reduce  speed,  change  formation). 

3.  When  an  element  leaves  a  field,  restore  its  condition  to 
the  normal  state. 

4.  Inside  the  field,  perform  designated  actions  (e.g.  detonate 
mines) . 

5.  Create  fields  at  the  beginning  of  the  simulation  and,  if 
required,  during  the  execution  of  the  simulation. 

6.  Destroy  fields  during  the  simulation  if  required. 

Since  the  Brigade  level  STAR  model  has  the  potential  for  modelling  over  a 
thousand  elements,  the  field  monitoring  routines  must  be  organized 
efficiently  to  avoid  excessive  overhead. 
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C.  Field  Actions 


Field  actions  are  things  that  happen  because  vehicles  encounter 
fields.  Typical  actions  which  can  be  simulated  include  the  following: 

1.  Change  speed. 

2.  Change  movement  formation. 

3.  Stop  for  a  given  time,  then  continue. 

4.  Go  into  a  hasty  defensive  posture. 

5.  Detonate  a  mine. 

6.  Lower  or  raise  mine  plow. 

7.  Call  for  artillery  or  air  strike. 

8.  Mount  or  dismount  infantry. 

9.  Change  movement  path  in  attempt  to  bypass  field. 

10.  Attempt  to  clear  obstacles  or  mines. 

11.  Attempt  river  crossing. 

12.  Respond  to  nuclear  effects  such  as  radiation,  fires, 
blowdown. 

The  field  actions  which  occur  for  a  given  field  will  typically  depend  on 
the  field  type  (e.g.  minefield),  on  parameters  of  the  field  (e.g.  mine 
density),  and  on  the  tactical  situation  (e.g.  under  fire?).  In  this 
section  we  discuss  the  general  concept  of  field  actions  and  how  they  are 
triggered.  Implementation  of  specific  actions  will  be  covered  in  Chapte. 
IV. 

There  are  two  distinct  kinds  of  field  actions.  Most  field  actions 
will  occur  immediately  when  vehicles  cross  the  field  boundaries  (entering 
or  exiting.)  These  actions,  which  we  will  call  boundary  actions,  are 
easily  triggered  at  the  Instant  of  entry  or  exit  if  the  movement  model  can 
detect  field  boundary  crossings.  Other  actions,  however,  occur  somewhere 
inside  the  field.  A  mine  detonation  is  the  most  obvious  example.  These 
actions  are  called  internal  actions.  They  are  initiated  by  a  field  entry, 
but  do  not  occur  until  the  vehicle  has  moved  into  the  field.  To  trigger 
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these  actions,  the  simulation  must  measure  the  distance  moved  since 
field  entry. 

It  should  be  noted  that  neither  type  of  field  action  can  be 
conveniently  modelled  by  scheduling  SIMSCRIPT  events.  This  is  because  a 
scheduled  event  occurs  after  a  designated  time  interval  has  passed 
whereas  field  actions  occur  at  designated  locations.  Since  vehicles  in 
STAR  need  not  move  at  constant  (or  easily  predictable)  speed,  it  is 
usually  impossible  to  predict  when  in  time  a  field  action  will  occur. 

Instead,  the  field  module  must  monitor  the  location  of  each  simulation 
element  with  respect  to  each  field  at  every  time  of  interest  in  the  simu¬ 
lation.  This  is  a  task  involving  a  potentially  huge  amount  of  computation. 

One  approach  to  monitoring  location  with  respect  to  fields  would 
use  the  movement  model.  For  each  element,  at  each  move  increment,  the 
procedure  would  loop  over  all  fields,  testing  whether  the  element  was  in 
the  field.  If  the  in/out  status  changed  from  a  previous  move  increment, 
then  a  boundary  action  would  be  performed.  This  approach  was  considered 
and  rejected  for  several  reasons: 

1.  Me  suspect  that  it  would  be  quite  expensive  to  compute. 

2.  The  approach  as  described  only  locates  field  boundaries 
to  the  accuracy  of  the  current  move  increment's  length. 

(This  could  be  overcome  with  additional  computation). 

3.  Internal  actions  cannot  be  easily  handled  using  this  approach. 

An  alternative  computational  scheme  is  implemented  in  the 

current  field  module.  For  each  element  we  compute  and  store  the  distance 
to  the  nearest  field  boundary  action  (entry,  or  exit)  in  the  element  attribute 
FLD.BOY.OIST(TANK) .  Similarly,  we  store  the  distance  (if  any)  to  a  pending 
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internal  action  in  the  attribute  FLD.INT.DIST(TANK).  Then  for  each  move 
increment  these  distances  are  decremented.  When  the  remaining  distance 
goes  to  zero,  the  appropriate  action  is  triggered  and  the  distance  to  the 
next  action  is  computed.  The  main  advantage  of  this  process  is  that  we 
need  to  loop  over  all  fields  only  when  a  new  distance  is  computed,  and 
this  will  only  be  necessary  when 

1.  The  vehicle's  direction  of  movement  changes. 

2.  The  vehicle  encounters  a  field  action. 

3.  New  fields  are  created  or  old  ones  destroyed. 

It  also  allows  increased  accuracy  and  handles  boundary  actions  and  internal 
actions  using  the  same  mechanism. 

Details  of  the  computation  are  reserved  for  Chapter  II. 

D.  Overlapping  Fields 

A  major  problem  which  must  be  considered  in  planning  the  Field 
module  is  the  problem  of  overlapping  fields.  If  an  element  can  be  in 
several  fields  simultaneously,  ambiguities  can  arise  as  to  the  intended 
field  actions.  The  geometry  of  the  field  module  can  recognize  multiple 
field  entries  and  exits  in  whatever  order  they  occur  without  any  problems. 
However,  making  the  action  routines  smart  enough  to  take  combinations  of 
fields  into  account  is  probably  prohibitively  complex. 

Unless  special  circumstances  dictate  otherwise,  we  plan  to  make 
the  field  action  routines  for  a  given  field  ignorant  of  whether  the  ele¬ 
ment  is  in  other  fields.  Thus  an  element  can  safely  be  in  two  (or  more) 
fields  at  one  time  as  long  as  those  fields  influence  different  aspects  of 
the  element's  behavior.  If,  however,  field  1  increases  an  element's  speed 
by  50%  and  field  2  decreases  speed  by  2  m./sec,  then  the  effect  of  being  in 


both  fields  will  be  ambiguous.  If  the  initial  speed  is  5  m/sec,  then 
the  resulting  speed  will  be  5.5  m/sec  if  field  1  is  entered  first,  or 
4.5  m/sec  if  field  2  is  entered  first.  The  user  should  be  aware  of  such 
possible  ambiguities  and  avoid  them  by  careful  definition  of  the  fields 
required  for  a  given  scenario. 

Overlapping  internal  actions  are  also  limited  by  the  computational 
procedure  of  the  Field  module.  Since  an  internal  action  is  initiated 
(planned)  when  the  field  is  entered,  but  doesn't  actually  occur  until  a 
designated  distance  into  the  field,  we  need  to  store  this  distance  for 
each  element  (as  an  attribute  called  FLD.INT.DIST) .  Since  only  one  such 
internal  distance  is  stored  for  each  element,  the  model  will  not  correctly 
simulate  an  element  which  is  simultaneously  in  two  different  fields  which 
both  involve  internal  actions. 

These  limitations  are  part  of  the  current  coding  of  the  Field  module. 
They  doubtless  could  be  overcome  by  more  involved  logic  at  an  increased 
cost  in  coding  effort,  computer  storage,  execution  time,  and  model  clarity. 
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II.  The  Field  Geometry  Module  for  STAR 

A.  Overview  of  the  Module 

This  chapter  discusses  the  details  of  the  geometric  aspects  of 
the  field  module.  These  include  the  definition  and  creation  of  fields 
and  the  process  of  monitoring  field  entry  and  exit.  The  Field  module 
involves  a  new  class  of  SIMSCRIPT  temporary  entities  (FIELDS),  along  with 
several  new  subroutines  for  processing  fields,  which  are  discussed  in 
this  chapter.  In  addition,  several  existing  routines  must  be  modified  to 
interface  with  the  new  module.  (Chapter  III). 

B.  The  Temporary  Entity  -  FIELD 

In  the  STAR  combat  simulation,  fields  are  modelled  as  elliptical 
overlays  on  the  terrain.  For  purposes  of  field  planning  and  model  input 
data  the  shape  of  each  field  ellipse  is  described  by  the  following  para¬ 
meters  (see  Fig.  1 . ) : 

XC.FLD\  X  and  Y  battlefield  coordinates  of  the 

YC.FLD  J  center  of  the  ellipse 

SMAJ.FLD  semi -major  axis  length 

SMIN.FLD  semi-minor  axis  length 

ANG.FLD  orientation  angle  in  radians  measured 

counterclockwise  from  east  to  the  major  axis. 

For  computational  purposes  the  boundary  of  the  field  is  described  by  the 

quadratic  equation 

PXX. FLD*(X-XC.FLD)**2  +  PYY.FLD*(Y-YC.FLD)**2 
+  PXY.FLD*(X-XC.FLD)*(Y-YC. FLD)  =  1.0 
Where  the  quadratic  coefficients  are  defined  as 

CANG  =  cos (ANG.FLD) 

SANG  =  sin(ANG.FLD) 

PXX.  FLD  =  (CANG/SMAJ . FLD)**2  +  (SANG/SMIN.FLD)**2 

PYY.FLD  =  ( SANG/SMAJ . FLD)**2  +  (CANG/SMIN.FLD)**2 

PXY. FLD  =  2*SANG*CANG*(1 ,0/SMAJ.FLD**2  -  1 .0/SMIN.FLD**2) 
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Field  Shape  Parameters 


Each  field  is  a  SIMSCRIPT  temporary  entity  in  the  entity  class 


FIELD.  The  computational  field  parameters  are  stored  as  entity  attributes 
as  follows: 


XC.FLD(FIELD) 

YC.FLD(FIELD) 

PXX. FLD(FIELD) 
PYY.FLD(FIELO) 

PXY. FLD(FIELD) 


Defined  as  above  -  all  are 
real  variables 


In  addition,  each  field  has  several  other  attributes: 


NAM.FLD  Sequential  ID  number  in  order 

of  creation  (Integer) 

TYP.FLD  Field  type  code  (Integer) 

Pl.FLD  )  Real  variables  defining  other 

P2.FLD  V  field  parameters  (e.g.  minefield 

P3.FLD  /  density)  which  influence  field  action 

P4.FLD  I  routines.  May  have  different  meanings 

for  different  field  types. 

The  distinction  between  the  field  type  and  the  P1-P4  parameters 
is  one  of  convenience.  If  two  fields  (say  a  scatterable  minefield  and  a 
dug-in  minefield)  will  both  use  the  same  field  action  routines,  then  they 
should  be  given  the  same  field  type,  and  the  parameters  should  be  used  to 
distinguish  between  them.  If,  however,  the  actions  triggered  by  one  field 
are  of  a  different  sort  than  those  resulting  from  the  other  field,  then 
different  field  type  codes  should  be  used  to  describe  them.  We  plan  to 
have  separate  dedicated  routines  to  trigger  the  actions  for  each  separate 
field  type.  Each  of  these  routines  can  use  any  or  all  of  the  P1-P4  para¬ 
meters.  Four  such  parameters  are  initially  provided  for;  ultimately  this 
number  may  change. 


C.  The  FLD.SET 

For  convenience  in  looping  over  the  currently  active  fields,  a  system- 

owned  set  called  the  FLD.SET  has  been  declared.  Each  field  entity  is 
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filed  in  the  FLD.SET  as  the  field  is  created.  For  as  long  as  the  field 
remains  in  the  FLD.SET,  the  simulation  will  consider  it  to  be  an  active 
field  and  will  process  it  in  all  field  module  computations.  If  a  field 
is  removed  from  the  FLD.SET,  then  the  field  module  will  ignore  it. 

D.  Routine  FLD. CREATE 

Field  entities  are  created  by  the  FLD. CREATE  routine.  In  a  typical 
STAR  run,  this  routine  will  be  called  several  times  by  the  FLD.INIT 
routine  before  the  start  of  the  simulation  to  initialize  all  fields  that 
are  in  place  at  the  start  of  the  battle.  Then  during  the  simulation, 

FLD. CREATE  may  be  called  at  any  time  to  create  dynamically  emplaced  fields 
(e.g.  artillery  scatterable  mines).  The  routine  assigns  the  next  unused 
sequence  number  to  the  NAM. FLD  attribute  of  the  new  field  and  returns  this 
value  so  that,  if  desired,  the  calling  program  can  refer  to  this  specific 
field  in  the  future. 

Given  Arguments 


xc 

(real ) 

X  coordinate  of  ellipse  center 

YC 

(real ) 

Y  coordinate  of  ellipse  center 

SAMAJ 

(real ) 

semi -major  axis  length 

SAM  IN 

(real ) 

semi -minor  axis  length 

ANGLE 

(real ) 

proper  angle  in  radians  from  east  to  major  axis 

TYPE 

(integer) 

field  type  code 

PI 

(real)  | 

P2 

P3 

(real)  l 
(real)  / 

field  parameters 

P4 

(real)  J 

Yielding  Argument 

NAME 

(integer) 

sequential  ID  number  of  this  field 

Local  Variables 

SANG 

(real) 

sin(ANGLE) 

CANG 

(real ) 

cos (ANGLE) 
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Global  Variables 


FLDS. CREATED  (integer)  counter  for  number  of  fields  created 

so  far 


FIELD  Entity  Attributes 

XC.FLD  See  section  B  of  the  chapter  for 

YC.FLD  definitions  -  all  are  set  by  this 

PXX. FLD  routine  for  the  newly  created  field. 

PYY.FLD 

PXY. FLD 
NAM.FLD 
TYP.FLD 
Pl.FLD 
P2.FLD 
P3.FLD 
P4.FLD 

Routines  Called 

None 

Events  Scheduled 
None 


Code  See  Figure  2. 


Brief  Description 


Line  7 
Lines  8-14 

Lines  15-17 
Lines  18-22 
Line  23 


Creates  the  new  field  entity 

Set  field  attributes  directly  from 
the  input  arguments 

Assign  the  sequence  number 

Compute  the  quadratic  coefficients 

Files  the  field  in  the  FLD.SET 


Use  Enter  with  descriptive  geometric  field  parameters. 

On  exit  the  new  field  is  created,  and  its  computational 
parameters  are  set. 
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1  ROUTINE  FLO. CREATE 

2  ”  CREATE  ONE  FIELD  ANO  SET  ITS  ATTRIBUTES 

3  GIVEN  XC.YC.SAMAJ.SAMIN. ANGLE. TTPE. FI. P2.P3.PV 

V  YIELDING  NAME 

5  NORMAL LT  NODE  IS  REAL 

6  DEFINE  TTPE.  NAME  AS  INTEGER  VARIABLES 

7  CREATE  A  FIELD 

8  LET  XC.fLO (FIELO)  •  XC 

9  LET  YC.FLD (FIELO)  -  TC 

10  LET  TYP. FLO  (FIELO)  •  TYPE 

11  LET  PI  .FLO  (FIELO)  >  PI 

12  LET  P2. FLO  (FIELD)  -  P2 

13  LET  P3. FLO  (FIELO)  «  P3 

IV  LET  PV.  FLO  (FIELD)  •  PV 

15  ADO  1  TO  FLOS. CREATED 

16  LET  NAN. FLO (FIELD)  •  FLOS. CREATED 

17  LET  NAME  •  FLOS.CREATEO 

18  LET  SANG  -  SIN. F (ANGLE) 

19  LET  CANG  •  COS. F (ANGLE) 

20  LET  PXX. FLO  (FIELD)  -  (CANG/SANAJ)  mm2  *  (SANG/SAH1N)  mm2 

21  LET  PTY. FLO  (FIELO)  -  (SANG/SANAJ)  mm2  *  (CANG/SAHIN)  mm2 

22  LET  PXY. FLO  (FIELD)  •  2mSANGnCANGm (I/SANAJmm2  -  ]/SAN1Nmm2) 

23  FILE  THIS  FIELD  IN  THE  FLO. SET 

2V  RETURN 

2S  END 


Figure  2.  FLD. CREATE  Routine 
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E.  Routine  FLD.INIT 


The  FLD.INIT  routine  is  called  once  by  MAIN  before  the  start  of 
simulation.  It  reads  cards  describing  the  fields  to  be  created  before 
the  simulation  starts  and  calls  FLD. CREATE  for  each  such  field.  The 
FLD.INIT  routine  is  then  released  from  MAIN.  The  code  in  Figure  3  is 
self  explanatory  with  the  possible  exception  of  line  9  which  converts  the 
angle  from  degrees  (on  the  input  card)  to  radians  for  the  simulation. 

F.  Routine  FLD.DIST 

The  FLD.DIST  routine  computes  the  distance  to  the  nearest  field 
boundary  along  an  element's  direction  of  movement.  The  resulting  distance 
is  stored  in  the  element's  FLD.BDY.DIST  attribute.  The  distance  is  com¬ 
puted  by  solving  the  quadratic  equation  for  the  intersection  of  the  ellipse 
boundary  with  the  movement  ray  as  folows: 

Let  XCUR.YCUR  be  the  current  element  location  and  DX,DY  the  components 
of  a  normalized  direction  vector  for  the  element, 
so  DX  =  cos (element  angle  of  movement) 
and  DY  =  sin(element  angle  of  movement). 

Then  X  =  XCUR  +  S*DX  ^ 

Y  =  YCUR  +  S*DX 

give  a  parametric  form  of  the  movement  path  where  the  parameter  S>0 
represents  distance  moved. 

The  ellipse  boundary  is  given  by 

PXX(X-XC)2  +  PYY(Y-YC)2  +  PXY ( X- XC ) ( Y- YC )  =  1.0,  (2) 

so  plugging  (1)  into  (2)  gives  a  quadratic  equation  in  S,  If  the 
quadratic  has  no  real  roots,  then  the  movement  path  does  not  intersect 
the  ellipse.  If  the  roots  are  SI  =  S2,  then  the  solution  is  a  tangency 

13 


it 


1  ROUTINE  FLO.  IN1T 

2  •*  CREATE  ALL  FIELOS  THAT  ARE  IN  PLACE  AT  THE  START  OF  THE  BATTLE 

3  NORMALLY  NODE  IS  REAL 

0  DEFINE  TYPE,  NUN.  I.  NAME  AS  INTEGER  VARIABLES 

5  USE  UNIT  S  FOR  INPUT 

6  READ  NUM 

7  FOR  I  -  1  TO  NUN  DO 

8  READ  XC.YC.SAHAJ.SAN1N. ANGLE, TYPE. PI, P2.P3. PA 

9  LET  ANGLE  ■  ANGLE /RAD I AN. C 

10  CALL  FLD. CREATE  GIVEN  XC, TC.SANAJ.SANIN. ANGLE, TYPE, PI . P2.P3.PM 

11  YIEL01NG  NAME 

12  LOOP 

13  RETURN 

111  END 


Figure  3,  FLD.INIT  Routine 
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and  we  ignore  it.  Otherwise  both  roots  exist  and  SI  <  S2.  Negative 
roots  correspond  to  boundaries  already  crossed,  while  positive  roots  cor¬ 
respond  to  boundaries  which  lie  ahead.  The  routine  loops  over  all  fields 


and  computes  the  smallest  positive  root. 


Given  Arguments 


VEH 

(Integer) 

Local  Variables 

D 

(double) 

DX 

(double) 

DY 

(double) 

XCUR 

(double)  \ 

YCUR 

(double)  J 

PXX 

(double)  ) 

PYY 

(double)  > 

PXY 

(double)  | 

A 

(double)  ) 

B 

(double)  / 

C 

(double)  / 

SI 

(double)  l 

S2 

(double)  j 

Element  Entity  Attributes 

X. CURRENT 

(real )1 

Y. CURRENT 

(real)/ 

DIR.OF.MVMT  (real ) J 
FLD.BDY.DIST  (real) 

Field  Entity  Attributes 


XC.FLO 

YC.FLD 

(real ) l 
(real) J 

PXX. FLD 
PYY.FLD 

PXY.  FLO 

(real )  \ 
(real) | 
(real) ) 

Routines  Called 
None 

Events  Scheduled 
None 


pointer  to  the  element  being  moved 


the  smallest  distance  found  so  far 

cos  of  element  movement  direction 
sin  of  element  movement  direction 

element's  current  location 

field  boundary  coefficients 

coefficients  of  the  quadratic  equation 
AS2  +  BS  +  C  -  0 

roots  of  the  quadratic  (if  they  exist) 
with  SI  <  S2 


element's  current  location  and  angle 
of  movement 

result  of  the  computation  -  distance  to 
nearest  boundary 


field  center  coordinates 
field  boundary  coefficients 
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Code  See  Figure  4 


o 


Brief  Explanation 
Line  9 
Lines  11-14 
Lines  15-42 
Lines  16-30 

Lines  31-38 

Line  47 

Use  The  FLO. GIST 


initializes  D  to  +  » 

setup  element  location  and  direction 

loop  over  each  field  in  FLD.SET 

compute  SI,  S2  if  they  exist,  otherwise 
cycle  to  next  field 

find  minimum  positive  value  among  SI,  S2,  D 
and  save  it  in  D 

stores  the  resulting  D  value  (maybe  +  ») 
in  the  element's  FLD.BDY.DIST  attribute 

routine  is  called  for  each  element  in  the  simulation 


when  the  element  is  created.  Whenever  an  element  changes  movement 
direction  or  crosses  a  field  boundary  the  routine  is  called  for 
that  element  to  give  a  new  FLD.BDY.DIST.  Note  that  the  distance 
finally  returned  is  limited  to  500m.  for  reasons  of  numerical 
roundoff  error.  This  forces  the  model  to  periodically  re-evaluate 
the  FLD.BDY.DIST  attribute. 
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26 
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29 

30 
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ROUT  1 NE  FLD.DIST 

••  COMPUTE  DISTANCE  FROM  VEH  TO  THE  CLOSEST  FIELD  BOUNDARY 
••  ALONG  CURRENT  DIRECTION  OF  MOVEMENT 
GIVEN  VEH 

DEFINE  OX.DT, XCUR, YCUR.OX.OY.PXX.PYY.PXY. A.B.C. ARG.SQ.Sl  .$2,0  AS  OOUBLE 
VARIABLES 

DEFINE  VEH  AS  AN  INTEGER  VARIABLE 
DEFINE  FIELD  AS  AN  INTEGER  VARIABLE 
LET  0  -  R1NF.C 
IF  FLOS. CREATED  NE  0 

LET  DX  •  COS.F  (DIR.OF.MVHT  (VEH) ) 

LET  OY  •  SIN.F  (DIR.OF.MVHT  (VEH)) 

LET  XCUR  •  X. CURRENT  (VEH) 

LET  YCUR  •  Y. CURRENT  (VEH) 

FOR  EVERY  FIELO  IN  FLO. SET  DO 

LET  OX  «  XCUR  -  XC.FLD  (FIELD) 

LET  OT  ■  YCUR  -  YC. FLO  (FIELD) 

LET  PXX  -  PXX. FLO  (FIELO) 

LET  PYY  ■  PYY.FLD  (FIELD) 

LET  PXY  ■  PXT. FLO  (FIELD) 

LET  A  ■  PXXmOXk«2  ♦  PYT«DYn«2  ♦  PXY«OX«OY 

LET  B  ■  2»PXX«0X«DX  *  2mPYY*QY«DT  ♦  PXY«  (OX«DY*OY«DX) 

LET  C  •  PXXmOXmh2  ♦  PYY«QY««2  ♦  PXYhQXnOY  -  1.0 
LET  ARG  ■  B««2  -  V.OmAmC 
IF  ARG  LE  0 
CYCLE 

ELSE 

LET  SO  *  SORT. F (ARG) 

LET  SI  -  -(B  ♦  SO)  /  (2.0»i A) 

LET  52  •  (SO  -  B)  /  (2.0* A) 

IF  St  GT  0.0 

IF  SI  LT  D 

LET  0  -  SI 

alnays 

CYCLE 

ELSE 

IF  S2  GT  0.0  AND  S2  LT  0 
LET  D  -  S2 

ALNAYS 
••END1F 
••END  IF 

LOOP 

IF  0  LT  RINF.C  AND  0  GT  500.0 
LET  0  •  500.0 
ALNAYS 
ALHATS 

LET  FLO.BOY.OIST  (VEH)  -  0 
RETURN 
END 


Figure  4.  FLD.DIST  Routine 
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III.  Interfacing  The  Field  Routines  with  STAR 

A.  Overview  of  Changes  Required 

Several  changes  in  the  existing  STAR  model  code  are  required  to 

implement  the  field  module.  For  the  most  part  these  changes  are  simple 

and  fairly  obvious,  but  in  one  case  (the  MOVE  routine)  substantial  effort 

was  required.  The  following  existing  program  segments  were  changed: 

PREAMBLE 

MAIN 

BL. CREATE 
RED. CREATE 
MOVE 

We  detail  the  required  changes  in  the  remaining  sections  of  this  chapter. 
Familiarity  with  the  basic  STAR  ground  model  is  assumed  (refs  [l]-[5]). 


B.  PREAMBLE 

1.  New  global  integer  variable  FLOS. CREATED 


2.  New  system  owned  set  FLD.SET 

3.  New  class  of  temporary  entities  FIELD  with  attributes 

NAM.FLD,  XC.FLD,  YC.FLD,  PXX.FLD,  PYY.FLD,  PXY.FLD, 
TYP.FLD,  Pl.FLD,  P2.FLD,  P3.FLD,  P4.FLD 
(see  Chapter  II  for  definition  and  type). 

A  FIELD  may  belong  to  the  FLD.SET. 

4.  New  attributes  for  the  TANK  (or  UNIT)  temporary  entity: 


5. 


FLD. INT.DIST 
FLD.BDY.DIST 
FLD. NO 

FLD.AKT 

FLD.INIT 


distance  to  pending  internal  action 

distance  to  nearest  field  boundary 

name  of  the  field  involved  in  any 
pending  internal  action 

code  describing  the  kind  of  action 
for  pending  internal  actions 

defined  as  a  releasable  routine. 
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1.  Immediately  following  the  call  to  RES. TERR, 

CALL  FLD.INIT  RELEASE  FLD.INIT 

to  create  fields. 

D.  BL. CREATE 

1.  Immediately  after  the  call  to  INIT.POS, 

CALL  FLD.DIST  (TANK) 

LET  FLD.INT.DIST(TANK)  =  RINF.C 

to  initialize  field  distance  attributes. 

E.  RED. CREATE 

1.  Immediately  after  the  call  to  INIT.POS, 

CALL  FLD.DIST(TANK) 

LET  FLD.INT.DIST(TANK)=  RINF.C 

to  initialize  field  distance  attributes. 

F.  MOVE 

The  changes  to  the  MOVE  routine  are  central  to  the  Field  module, 
and  are  the  most  critical.  In  this  section  we  explain  these  changes  in 
detail.  To  aid  in  understanding  the  relation  of  these  changes  to  the  rest 
of  the  MOVE  routine,  we  include  a  listing  of  the  entire  routine  in  Figure 
5,  with  changes  flagged  by  "FLD  in  the  right  hand  margin  of  the  card.  The 
reader  is  assumed  to  be  familiar  with  the  MOVE  routine  as  documented  in 
reference  [4]. 

1.  (Lines  157-161)  Whenever  a  vehicle  changes  its  direction  of 
movement,  the  previously  computed  FLD.BDY.DIST  is  no  longer 
valid,  and  must  be  recomputed  by  a  call  to  FLD.DIST 


2.  (Lines  170-171)  The  distance  limit  for  a  move  increment 
includes  FLD.INT.DIST  (to  trigger  internal  actions)  and 
FLD.BDY.DIST  +  1  (to  trigger  boundary  actions).  The  +1  is 
included  to  make  sure  that  the  boundary  is  actually  crossed 
(by  up  to  1  meter)  before  the  action  is  triggered.  This 
prevents  roundoff  noise  from  triggering  the  same  action  more 
than  one  time. 

3.  (Lines  215-227)  At  the  end  of  each  movement  increment,  if 
there  are  any  fields  in  the  battle,  FLD.BDY.DIST  and  FLD.INT.DIST 
are  updated.  If  either  distance  hits  zero,  the  FLD.ACT  routine 
is  called  to  decode  and  perform  the  action.  If  as  a  result  of 
the  field  action,  the  vehicle  can  no  longer  move,  the  call  to 
MOVE  is  terminated.  Finally,  if  we  are  within  50  meters  of  a 
boundary,  the  FLD.DIST  routine  is  called  to  get  a  more  accurate 
FLD.BDY.DIST.  This  extra  call  is  required  because  of  round-off 
errors  on  the  IBM- 360  where  vehicle  X  and  Y  coordinates  have 
about  6  significant  digits  on  a  battlefield  which  may  be  100,000 
meters  deep. 
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1  ROUTINE  TO  MOVE  GIVEN  VEH 

2  DEFINE  K  AS  AN  INTEGER  VARIABLE 

3  DEFINE  SLOPE  AS  A  REAL  VARIABLE 

V  DEFINE  REM. ROVE. TINE,  DEL.X.  DEL . T,  D.TO.MCP.  ALPH.  SALPH, 

5  CALPH,  GRAD.X.  GRAD.T,  SPD. LIMIT.  ACCEL. LIMIT,  DECEL. LIMIT, 

6  OIST. LIMIT,  DEL. SPD.  OIST.INCA.  TIME. I  NCR  AS  REAL  VARIABLES 

7  DEFINE  DIST.REQ,  TIME. RED,  ZERO. LEVEL  AS  REAL  VARIABLES 

8  DEFINE  X.DEST,  T.DEST,  DIR,  CX.  CT.  NX,  NT,  LX,  LT.  NLX,  NLT,  PX.PT. 

9  NPX,  NPT,  X.OFF,  T.OFF.  D.TO.DEST  AS  REAL  VARIABLES 

10  DEFINE  THETA,  CTH,  STH  AS  REAL  VARIABLES 

11  DEFINE  VEH.  FINAL  AS  INTEGER  VARIABLES 

12  DEFINE  MST,  RT,  NM.  MCP.INC.  LN.  MCP,  D.ON.RT  AS  INTEGER  VARIABLES 

13  DEFINE  FAKE. MCP  AS  AN  INTEGER  VARIABLE 

IN  DEFINE  1  AND  J  AS  INTEGER  VARIABLES 

15  CHECKOUT  VEH  ALWAYS 

16  LET  ZERO. LEVEL  •  1.0  LET  FINAL  -  0 

17  LET  MST  ■  MV. STATE  (VEH) 

18  IF  MST  -  0  OR  MST  >-  A  RETURN 

19  ELSE 

20  IF  MST  EQUALS  1 

21  CALL  RT.SEL  (VEH) 

22  LET  MV. STATE (VEH)  -  2 

23  ALHATS 

21  LET  REM. MOVE. TIME  *  TIME.V  -  T.SPD(VEH) 

25  LET  RT  -  ROUTE  (VEH. 

26  LET  D.ON.RT  -  DIR. ON. RT (VEH) 

27  LET  FAKE. MCP  ■  0 

28  IF  RT  EOUALS  0  LET  D.TO.MCP  •  RINF.C  GO  TO  ANGLES 

29  ELSE 

30  ’’CONSISTENCY  CHECK  FOR  POSSIBLE  TURNAROUND 

31  IF  AREA. START (VEH)  LT  AREA. END (VEH) 

32  IF  O.ON.RT  EO  0  GO  TO  NEW. MCP 

33  ELSE  LET  O.ON.RT  »  0 

3V  LET  OIR.ON.RT (VEH)  •  0 

35  LET  K  -  DIM. F (ROUTE. DATA  (AT. «)) /3 

36  LET  MCP  *  NEXT. MCP  (VEH) 

37  IF  MCP  EQ  0  LET  NEXT. MCP  (VEH)  -  1 

38  ELSE  IF  MCP  EQ  K  LET  NEXT. MCP (VEH)  -  0 

39  ELSE  LET  NEXT. MCP (VEH)  •  MCP  ♦  1 

■JO  ALWAYS 

VI  ALWAYS 

V2  ELSE  ’’AREA. START  GT  AREA. END 

V3  IF  O.ON.RT  EO  1  GO  TO  NEW. MCP 

VV  ELSE  LET  D.ON.RT  •  I 

VS  LET  OIR.ON.RT  (VEH)  -  I 

V6  LET  K  •  DIM. F  (ROUTE. DATA  (RT,«) ) /3 

V7  LET  MCP  -  NEXT. MCP (VEH) 

V6  IF  MCP  EO  0  LET  NEXT. MCP  (VEH)  -  K 

V9  ELSE  IF  MCP  EQ  I  LET  NEXT. MCP (VEH)  •  0 

50  ELSE  LET  NEXT. MCP (VEH)  -  MCP  -I 

Figure  5.  MOVE  Routine 
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ALWAYS 

ALWAYS 

ALWAYS 

’NEW. MCP’  LET  MCP  »  NEXT. MCP  (VEH)  LET  NM  -  MCP  •<  3 
IF  HCP  EQUALS  0  "HOVE  TO  POSITION  IN  AREA. END 

IF  POS.  IN.PLT.AREA  IVEH)  EQUALS  0,  CALL  BEST.POS  IVEH)  "SETTING 
ALWAYS 

LET  I  -  PLT  (VEH)  LET  K  -  POS.  IN.PLT.AREA  (VEH)  •<  3 
FOR  J  *  1  TO  01M.F  (POSITION (I  ,k.m)  )  WITH  POSITION (I . J. 1)  EQUALS 
AREA. END  (VEH) 

DO 

LET  X.OEST  -  POSITION (1 .  J.K-l) 

LET  Y.DEST  -  POSITION (l.J.K) 

LET  DIR  =  POSITION  (1 ,  J.  K+1 ) 

LOOP 

LET  D. TO. HCP  *  SORT .F  ( (X. DEST-X. CURRENT (VEH) ) ««2  ♦ 

(Y.DEST-Y.  CURRENT  (VEH) )  mm2) 

IF  0. TO. HCP  LESS  THAN  ZERO. LEVEL. 

LET  MV. STATE  (VEH)  «  4 
LET  OIR.OF.MVMT (VEH)  -  DIR 
LET  PRI.OIR(VEH)  -  DIR 
LET  SPO(VEH)  *  0. 

LET  FINAL  -  1 
GO  TO  NEH.1NCR 

ELSE 

GO  TO  0IRN.C6MP 

ELSE 

IF  FORM. CODE  (VEH)  EQUALS  0  "GO  DIRECTLY  TO  NEXT  MCP 

LET  X.OEST  -  ROUTE. DATA (RT.NM-2) 

LET  Y.OEST  -  ROUTE. ORTA (RT.NH-1) 

LET  D. TO. MCP  ■  SORT.  F  ((X.  DEST-X.  CURRENT  (VEH))  «>«2  ♦ 

(Y.DEST-Y. CURRENT  (VEH) )  ««2) 

GO  TO  DIRN.COMP 

ELSE  "MOVE  ALONG  ROUTE  OFFSET  BY  FORMATION 

IF  MCP  EQUALS  1  AND  D.ON.RT  EQUALS  0  "TOWARD  FIRST  HCP 

LET  NX  >  ROUTE. DATA (RT. 4) 

LET  NY  -  ROUTE. DATA (RT. 5) 

LET  LX  »  ROUTE. DATA (RT, 1) 

LET  LY  =  ROUTE. DATA (RT, 2) 

LET  I  -  ROUTE .  DATA  (AT,  3) 


SETTING  POS. IN. PLT. A 


LET  K  *  DIM. F  (ROUTE. OATAIRT.*)) 

IF  MCP  EQUALS  K/3  AND  D.ON.RT  EOUALS  ) 
LET  NX  -  ROUTE. DATA (RT.K-5) 

LET  NY  -  ROUTE. DATA (RT.K-4) 

LET  LX  -  ROUTE. DATA (RT.K-2) 

LET  LY  *  ROUTE. OATA(RT.K-l) 

LET  I  *  ROUTE. DATA (RT.K-3) 

ELSE  GO  TO  INTERMEO 
ALWAYS 


'TONRRD  LAST  MCP  GOING  BACKWARD 


Figure  5  (Continued). 
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ALWAYS 

LET  NLX  -  NX-LX  LET  NLT  *  NT-LT 

IF  I  EQUALS  0,  LET  I  •  FORM. CODE  IVEhl 
ALWAYS 

LET  J  -  FORM.  POS  (VEH)  «  2 
LET  X. OFF  -  FORM. OFFSET  11. J-l) 

LET  Y.OFF  ■  FORM. OFFSET  (I. J) 

LET  THETA  *  ARCTAN.F  INLY, NLX) 

LET  CTH  -  COS. F  (THETA) 

LET  STH  -  SIN. F (THETA) 

LET  X.OEST  «  LX  ♦  (X.OFF  ♦  FOR.CHG. INT) *CTH  -  Y.OFFmSTH 
LET  Y.OEST  «  LY  ♦  (X.OFF  ♦  FOR.CHG. INT) «STH  ♦  Y.OFF  «  CTH 
LET  D.  TO.MCP  -  SORT.F  (  (X.DEST-X. CURRENT  (VEH)  1  **2  *  IY.OEST-Y. CURRENT  (VEH)  1 
m»2) 

GO  TO  01RN.C0MP 

’INTERNED *  "TO  HERE  FOR  INTERMEDIATE  MCP’S  ON  ROUTE 
LET  CX  •  X. CURRENT  (VEH)  LET  CY  ■  Y. CURRENT  (VEH) 

IF  D.ON.RT  EQUALS  0  LET  LM  ■  NM  -  3 

ELSE  LET  LM  -  NM  ♦  3 

ALWAYS 

LET  NX  -  ROUTE. DATA  (RT.NM-2) 

LET  NY  »  ROUTE. DATA  (RT.NM-1) 

LET  LX  -  ROUTE. DATA  (RT.LM-2) 

LET  LY  *  ROUTE. DATA  (RT, LM- 1 1 

LET  NLX  «  NX  -  LX  LET  NLY  *  NY  -  LY 

LET  ALPH  «-  ((CX-NKIxULK  *  (CY-NY)  *NLY)  /  1NLX*NLX  ♦  NLY-NLY) 

LET  PX  «  ALPH  *  IX  *  (1.  -  ALPH)  «  NX 

LET  PT  »  ALPH  «  LT  *  II.  -  ALPH)  »  NT 

LET  NPX  •  NX  -  PX  LET  NPY  «  NT  -  PY 

LET  1  -  ROUTE. DATA  (RT, NM*3*  (D. ON. RT- 1 ) ) 

IF  1  EQUALS  0,  LET  I  »  FORM. CODE  (VEH) 

ALWAYS 

LET  J  -  FORM. POS  (VEH)  «  2 
LET  X.OFF  ■  FORM. OFFSET  (1, J-l) 

LET  Y.OFF  «  FORM. OFFSET  (I,  J) 

LET  0. TO.MCP  •  SQRT.F  (NPX«NPX  ♦  NPTxNPT) 

IF  D. TO.MCP  LESS  THAN  ZERO. LEVEL  GO  TO  MCP. REACHED 
ELSE 

LET  THETA  *  ARCTAN.F  (NLY, NLX) 

LET  CTH  -  COS. F  (THETA) 

LET  STH  -  SIN. F  (THETAI 

LET  ALPH  «  FOR.CHG. INT  /  0. TO. MCP 

LET  X.OEST  •  PX  ♦  ALPH  k  NPX  ♦  X.OFF  «  CTH  -  Y.OFF  *  STH 

LET  Y.DEST  -  PT  ♦  ALPH  «  NPY  ♦  Y.OFF  «  CTH  ♦  X.OFF  «  STH 

LET  O.TO.DEST  •  SQRT.F  ( (X.OEST-CX)  »«2  ♦  (Y.DEST  -CY)««2) 

IF  0. TO.OEST  IS  LESS  THAN  D. TO. MCP 
LET  D. TO. MCP  -  D. TO.OEST 

LET  FAKE. MCP  •  1 

ELSE  LET  FAKE. MCP  -  0 

ALWAYS 


Figure  5  (Continued), 
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151  'D1RN.C0HP' 

152  IF  O.TO.MCP  IS  LESS  THAN  ZERO. LEVEL. 

153  GO  TO  HCP. REACHED 

1SU  ELSE 

155  LET  OEL.X  -  X.OEST  -  X. CURRENT  (VEH) 

156  LET  DEL.T  •  T.DEST  -  T. CURRENT  (VEH) 


157  LET  OIR  •  DIR.OF.HVHT  (VEH)  * ‘FLO 

158  LET  DIR.OF.HVHT (VEH)  -  ARCTAN. F  (DEL. T .DEL. X) 

159  IF  ABS.F  (D1R-D1R.OF.HVHT  (VEH)  I  GT0.02  *  "FLD 

160  CALL  FLO. GIST  (VEH)  “TO  COHPUTE  HEM  FLD.BOT.DIST  FLD 

161  ALWAYS  “FLD 

162  'ANGLES' 


163  LET  SALPH  -  SIN. F  (DIR.OF.HVHT  (VEH) )  LET  CALPH  •  COS. F  (DIR.OF.HVHT  (VEHI ) 

1 64  ’NEW. 1NCR*  CALL  ELEVG  (X . CURRENT (VEH) . T. CURRENT (VEH) )  YIELDING  Z. CURRENT (VEH) . 

165  GRAD. X ,  GRAO.Y 

166  IF  FINAL  EQUALS  1.  GO  TO  END. HOVE 

167  ELSE 

168  LET  SLOPE  -  GRRO.X  *  CALPH  ♦  GRAD. Y  *  SALPH 

169  CALL  MOVE. LIMITS  GIVEN  VEH.  SLOPE  YIELDING  SPO. LIMIT.  ACCEL. LIMIT.  DECEL. LIMIT 

170  LET  DIST. LIMIT  «  HIN.  F  (0.  TO.  HCP.  MAX.  D I  ST .  1NCR,  “FLD 

171  FLO.  INT.  DIST  (VEH)  .  (1  ♦  FLD.BOT.DIST  (VEH) ) )  “FLD 

172  LET  DEL. SPO*  SPD. LIMIT  -  SPD (VEH) 

173  IF  ABS.F  (DEL. SPO)  LT  0.1. 

1 74  “EASY  CASE  --  NO  ACCELERATION  — 

175  LET  0IST.1NCR  «  REM. MOVE. TIME  «  SPO. LIMIT 

176  IF  DIST. I  NCR  IS  GREATER  THAN  DIST. LIMIT. 

177  “MOVE  STOPPED  BY  DISTANCE  LIMIT 

178  LET  QIST.1NCR  »  DIST. LIMIT 

179  LET  TIME. I  NCR  -  DIST. INCA  /  SPD. LIMIT 

180  ELSE 

181  “MOVE  STOPPED  BY  TIME  LIMIT 

182  LET  Tine. INCH  »  REM. MOVE. TIME 

183  ALWAYS  GO  TO  MOVE. IT 

181  ELSE  “HARD  CASE  —  ACCELERATION  REQUIRED  — 

185  IF  DEL. SPO  IS  LESS  THAN  0.  LET  ACCEL. LIMIT  »  DECEL. LIMIT 

186  ALWAYS  LET  TIME. RED  ■  OEL.SPO  /  ACCEL. LIMIT 

187  LET  OIST.REO  »  SPO (VEH) *T I  ME. REQ  ♦  0.5  »  ACCEL. LIMIT  «  T1ME.REQ  ««2 

188  IF  TIME. RED  IS  GREATER  THAN  REM. MOVE. TIME. 

189  “SPO. LIMIT  CANNOTBE  ATTAINEO  IN  REMAINING  TIME,  SO  CHANGE  LIMIT 

190  LET  SPO. LIMIT  •  SPO  (VEH)  ♦  ACCEL. LIMIT  «  REM. MOVE. TIME 

191  LET  01ST.INCR  -  SPD (VEH)  «  REM. MOVE. TIME  ♦  0.5  «  ACCEL. LIMIT  « 

192  REM. MOVE.  TIME  «*.  2 

193  ELSE  “SPD. LIMIT  CAN  BE  ATTAINED 

19V  LET  01ST.1NCR  -  OIST.REQ  ♦  (REM. MOVE. TIME  -  TIME. REQ) «SP0. LIMIT 

195  ALMATS 

196  IF  OIST.INCR  IS  LESS  THAN  DIST. LIMIT. 

197  “MOVE  HILL  BE  STOPPEO  BY  TIME  LIMIT 

198  LET  TIME. I  NCR  -  REM. MOVE. TIME 

199  LET  SPD  (VEH)  •  SPD. LIMIT 

200  ELSE  “MOVE  STOPPED  BY  DISTANCE  LIMIT 
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LET  01  ST. INCH  ■  D1ST. LIMIT 
IF  OIST. LIMIT  IS  LESS  THAN  D1ST.RE0. 

LET  TIME. I  NCR  •  (SORT . F  (SPD  (VEH) «a2+2. "ACCEL . L IMITmOIST . L INI T1 
-SPD  (VEH) I /ACCEL. LIMIT 
AOO  TIME. INCA  *  ACCEL. LIMIT  TO  SPDtVEM) 

ELSE 

LET  TIME. 1NCR  -  TIME. REO  ♦  101ST.LIHIT~DIST.REO) /SPD. LIMIT 
LET  SPD  (VEH) -SPD. LIMIT 
ALWAYS 
ALWAYS 

‘MOVE. IT*  SUBTRACT  TIME. 1NCR  FROM  REM. MOVE. T 1ME 
ADO  01ST.1NCR  x  CALPH  TO  X. CURRENT (VEH) 

AOO  01ST.INCR  *  SALPH  TO  Y. CURRENT  (VEH1 
SUBTRACT  01ST.1NCR  FROM  D.TO.HCP 
IF  FLOS. CREATED  GT  0 


SUBTRACT  DIST.1NCR  FROM  FLO. BOY. OIST  (VEH)  * “FLO 

SUBTRACT  OIST.INCR  FROM  FLO. INT. OIST  (VEH)  **FLO 

IF  FLO. INT. OIST  (VEH)  LE  0.0  OR  FLD.BOY.DIST (VEH)  LE  0.0  *  *FLD 

CALL  FLO. ACT  (VEH)  * *FLO 

IF  KKILL  (VEH)  EO  1  OR  MKILL  (VEH)  EO  1  "FLO 

LET  FINAL  -  1  **FLO 

ALWAYS  *  'FLO 

ALWAYS  **FLD 


IF  FLO. BOY. OIST  (VEH)  LT  50.0 
CALL  FLO. OIST (VEH) 

ALWAYS 

ALWAYS 

IF  REM. MOVE. TIME  LT  0.01.  LET  FINAL-1 
REGARDLESS 

IF  O.TO.MCP  IS  LESS  THAN  ZERO. LEVEL. 

•MCP.REACHEO* 

IF  FAKE.MCP  EQUALS  1 
LET  FAKE.MCP  •  0 
GO  TO  NEW.MCP 

ELSE 

IF  MCP  -  0 

LET  FINAL  -  1 
GO  TO  NEW.MCP 

ELSE 

IF  DIR. ON. RT (VEH)  EQUALS  0  ' ’MCP  NUMBERS  INCREASE 

IF  NEXT. MCP  (VEH)  EQUALS  DIM. F  (ROUTE. DATA (ROUTE  (VEH) .«)) /3 
LET  NEXT. MCP  (VEH)  •  0 
GO  TO  NEW.MCP 

ELSE 

AOO  I  TO  NEXT. MCP  (VEH)  GO  TO  NEW.MCP 
ELSE  *  *MCP  NUMBERS  DECREASE 

IF  NEXT. MCP (VEHI  EOUALS  1 
LET  NEXT. MCP  (VEHI -0 
GO  TO  NEW.MCP 


ELSE 


Figure  5  (Continued), 
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25 J  SUBTRACT  1  FROM  NEXT.HCP «VEH1 

252  ELSE  GO  TO  NEW. I NCR 

253  'END. HOVE*  LET  T.SPOIVEH)  *  T1HE.V 

25V  RETURN 

255  END 


Figure  5  (Continued). 


GO 
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IV.  Field  Actions 

The  final  aspect  of  the  Field  module  which  we  must  discuss  is  the 
implementation  of  field  actions.  As  indicated  in  Chapter  I,  field  actions 
occur  as  a  result  of  a  vehicle  encountering  a  field  boundary.  Actions 
which  occur  immediately  are  called  field  boundary  actions.  Actions  which 
are  planned  for  later  occurrence  are  called  field  internal  actions. 

A.  Deciding  Which  Action  to  Perform 

When  the  FLD.ACT  routine  is  called  from  the  MOVE  routine,  it  must 
decide  which  field  action(s)  to  perform.  Figure  6  shows  a  partial  listing 
of  a  FLD.ACT  routine.  Details  of  particular  actions  are  not  included  since 
they  are  quite  dependent  on  the  scenario  plan  for  a  given  study.  Examples 
of  how  typical  actions  might  be  handled  are  given  in  section  B  of  this 
chapter.  What  this  code  segment  does  show  is  the  procedure  for  deciding 
whether  entry .internal ,  or  exit  actions  should  occur,  and  in  each  case, 
the  field  involved. 

If  FLD. INT . ACT ( VEH )  has  been  decremented  to  zero,  then  a  previously 
planned  internal  action  should  occur,  (lines  4-11).  The  field  for  which 
this  action  was  planned  is  indicated  in  the  vehicle's  FLD. NO  attribute  and 
the  action  type  is  given  by  the  vehicle's  FLD.AKT  attribute.  Note  that  at 
most  one  such  action  can  be  pending  at  any  one  time.  A  typical  internal 
action  is  a  mine  detonation  which  would  call  POP. A. MINE  to  assess  lethality 
and,  if  the  vehicle  survived,  would  initiate  evasive  action  and  plan  the 
next  detonation  for  this  vehicle. 

If  FLD.BDY.DIST(VEH)  has  been  decremented  to  zero,  then  a  boundary 
action  should  occur.  A  given  move  increment  may,  in  some  circumstances, 
cross  more  than  one  field  boundary.  Thus,  instead  of  storing  the  field 
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1  ROUTINE  FLD.ACTlVEH)  **  SORTS  OUT  WHICH  FIELD  RCTIONS  TO  PERFORN 

2  DEFINE  VEH. FIELD  RS  INTEGER  VARIABLES 

S  DEFINE  OX. OT. XCUR. TCUR. OX, OT. PXX. PXT, PTT. A.B.C, ARC. SO, 51. 32  AS  DOUBLE  VARIABLES 

4  IF  FLO. 1NT.01ST (VEH)  LE  0.0 

5  PRINT  1  LINE  NITH  NANE  (VEH)  .X.  CURRENT  (VEH)  .T. CURRENT  (VEHI  .FLO. NO  (VEH) . 

5  TINE.V  AS  FOLLOWS 

7  FLO  INT  ACT  VEH'Hhkm  LOCN  ■  nhmkmm  hmhmhh  FIELD  •  «•«•««  TINE  ■  «««* 

6 

9  *’  HERE  WE  CALL  ROUTINES  TO  PERFORN  INTERNAL  ACTIONS 

10 

1 1  ALWATS 

12  IF  FLD.BDT.01ST  (VEH)  LE  0.0 

13  LET  OX  •  COS.F  (OIR.OF.HVNT  (VEH) ) 

14  LET  OT  •  SIN.F  (OIR.OF.HVNT  (VEHI) 

15  LET  XCUR  •  X. CURRENT (VEH) 

16  LET  TCUR  •  T. CURRENT (VEH) 

17  FOR  EVERT  FIELD  IN  FLO. SET  DO 

18  LET  OX  •  XCUR  -  XC. FLO  (FIELD) 

19  LET  OT  •  TCUR  -  TC. FLO  (FIELD) 

20  LET  PXX  «  PXX. FLO  (FIELD) 

21  LET  PTT  -  PTT. FLO  (FIELD) 

22  LET  PXT  -  PXT. FLO  (FIELD) 

23  LET  A  -  PXX«0Xm*2  *  PTTmOTmm2  *  PXTmDXmDT 

24  LET  B  -  2»PXX«QX«DX  ♦  2«PTTmQT»DT  *  PXT«  (QXmDT+QThDX) 

25  LET  C  •  PXX«QXmm2  *  PTT«0Th*2  *  PXTmOXmOT  -  1.0 

26  LET  ARG  •  B««2  -  4.0»A«C 

27  IF  ARG  LE  0 

28  CTCLE 

29  ELSE 

50  LET  SO  -  SORT. F  (ARC) 

51  LET  SI  -  -  (B  *  SO)  /  (2.0hA) 

32  LET  $2  •  (SO  -  BI/(2.0«Al 

S3  IF  31  LE  0.0  AND  SI  G£  -2.0 

34  PRINT  1  LINE  WITH  NANE  (VEH) .XCUR. TCUR.NAH.FL0  (FIELD) . 

35  TINE.V  AS  FOLLOWS 

36  FIELD  ENTRT  VEH-m««k  LOCN  -  mhmohh  FIELD  -  mmkm  TINE  «  mmnn 

37 

38  "  HERE  HE  CALL  ROUTINES  TO  PERFORN  FIELD  ENTRT  BOUNDART  ACTIONS 

39 

40  ALWATS 

41  IF  S2  LE  0.0  AND  S2  GE  -2.0 

42  PRINT  1  LINE  WITH  NANE (VEH) . XCUR. TCUR.NAH. FLO  (FIELD) , 

43  TINE.V  AS  FOLLOWS 

44  FIELD  EXIT  VEH-mmmm  LOCN  •  mmiM  hmhhhm  FIELD  •  """"  TINE  ■  tutm* 

45 

46  *’  HERE  WE  CALL  ROUTINES  TO  PERFORN  FIELD  EXIT  BOUNDART  ACTIONS 

47 

46  IF  NAN.  FLO  (FIELD)  EQ  FLO. NO  (VEH) 

49  LET  FLO. INT.DIST (VEH)  -  R1NF.C 

50  LET  FLO. NO (VEH)  -  0 

Figure  6.  Partial  FLD.ACT  Routine 
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51  ALWAYS 

52  ALWAYS 

53  * ’END IF 

SU  LOOP 

55  ALWAYS 

56  CALL  FLO.  01  ST  IVEH) 

57  RETUHN 

56  END 


Figure  6  (Continued). 
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number  for  a  boundary  action  on  the  vehicle,  we  test  each  field  for 
boundary  crossing  whenever  FLD.ACT  is  called  with  FLD.BDY.DIST  <_  0.  The 
loop  to  implement  this  test  is  contained  in  lines  17  to  54.  Note  the 
tolerance  of  +  1  meter  in  lines  33  and  41.  If  this  tolerance  is  decreased, 
some  field  entries  or  exits  may  be  missed. 

Regardless  of  the  actions  triggered  in  FLD.ACT,  the  FLD.BDY.DIST 
is  recomputed  prior  to  return  to  set  up  the  next  boundary  crossing. 

B.  Implementing  Some  Typical  Actions 

In  this  section  we  provide  suggestions  for  implementing  some  pos¬ 
sible  field  actions.  In  many  cases,  an  action  performed  on  entering  a 
field  must  be  paired  with  a  complementary  action  on  exit  which  restores 
the  vehicle  to  its  previous  state.  This  requires  either  saving  the  previous 
state  for  those  attributes  affected  by  the  field  or  having  a  default  back¬ 
ground  state  to  which  exiting  vehicles  return. 

The  choice  of  field  action  to  perform  may,  in  some  cases,  depend 
on  the  type  of  "vehicle"  encountering  the  field  -  an  obstacle  that  totally 
stops  wheeled  vehicles  may  merely  slow  tanks  and  may  be  no  hindrance  at  all 
for  dismounted  infantry.  In  this  section  we  assume  that  the  choice  of 
actions  to  perform  will  be  determined  by  the  scenario  writers  and  tacticians. 

1 .  Change  Speed 

A  frequent  result  of  entering  a  field  is  a  change  in  speed  (e.g. 
for  an  obstacle  field).  In  this  section  we  discuss  speed  changes  which 
do  not  completely  stop  the  vehicle.  Simply  changing  the  vehicle's  SPD 
attribute  on  field  entry  will  NOT  suffice,  because  this  attribute  is  reset 
at  every  move  increment  based  on  the  results  of  a  call  to  routine  MOVE. LIMITS. 
One  way  of  implementing  a  speed  change  would  be  to  define  a  new  vehicle 


attribute  FLD.SPD.FAC  the  field  speed  factor  for  the  vehicle.  When  the 
vehicle  is  not  in  any  field,  FLD.SPD.FAC  assumes  a  background  value  of  1.0. 
On  field  entry  the  FLD.ACT  routine  would  set  FLD.SPD.FAC  to  a  value 
greater  than  1.0  for  a  speed  increase  and  less  than  1.0  for  a  speed 
decrease.  (The  value  would  be  one  of  the  field  parameters  PI  -  P4).  The 
MOVE. LIMITS  routine  would  include  FLD.SPD.FAC  in  its  computation  of 
vehicle  target  speed  for  each  move  increment.  On  field  exit,  FLD.ACT  sets 
FLD.SPD.FAC  back  to  1.0. 

2.  Stop  for  T  Seconds 

To  simulate  a  brief  delay  on  field  entry,  the  FLD.ACT  routine 
can  simply  set  the  vehicle's  MV. STATE  to  3  (Stop  along  route).  The  vehicle 
will  stop  as  soon  as  it  is  physically  possible.  For  a  longer  delay,  we 
probably  also  want  to  set  the  vehicle's  DEFNUM  to  simulate  taking  advantage 
of  available  cover.  In  either  case,  once  the  vehicle  is  stopped  it  will 
not  trigger  further  field  action.  To  get  the  vehicle  started  again  after 
T  seconds  (a  field  parameter),  a  new  event  must  be  scheduled  by  the  field 
entry  routine.  No  field  action  is  required  on  field  exit.  Similar  comments 
apply  to  the  hasty  defense  action. 

3.  Response  to  Minefields 

A  variety  of  actions  may  be  appropriate  for  simulating  a  vehicle 
encountering  a  minefield.  The  first  question  which  must  be  asked  is  whether 
the  vehicle  notices  the  minefield:  Several  cases  can  occur: 

a)  Minefield  detected  on  entry  -  Then  the  field  entry 

action  routine  can  initiate  any  desired  vehicle  responses 
and  will  plan  an  internal  mine  detonation  action. 
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b)  Minefield  not  detected  -  Then  the  field  entry  action 
routine  only  plans  the  internal  mine  detonation  action, 
and  the  vehicle  simply  drives  on.  When  the  first  deto¬ 
nation  occurs,  the  minefield  is  assumed  detected  and 
appropriate  responses  are  taken  by  the  detonating  vehicle 
and  other  vehicles  in  his  immediate  unit. 

c)  Minefield  detected  prior  to  entry  -  A  clearly  visible 
field  can  be  modelled  by  two  concentric  field  ellipses. 
Entering  the  larger  ellipse  triggers  the  field  detection 
and  any  responses  thereto.  Entering  the  smaller  ellipse 
initiates  mine  detonation  actions. 

Given  that  a  vehicle  has  detected  the  minefield,  several  actions 
may  be  appropriate  for  it  and  for  other  vehicles  in  its  immediate  unit 
(perhaps  platoon).  If  mine  plows  or  rollers  are  available,  they  may  be 
used  (vehicle  PLOW.COND  attribute).  This  probably  requires  a  brief  stop. 
Vehicles  without  plows  may  line  up  behind  those  with  plows  (a  formation 
change).  The  resulting  unit  will  move  slower  while  plowing  (speed  change). 

A  more  difficult  action  is  an  attempt  to  bypass  the  field.  This 
would  involve  creation  of  special  routes  for  moving  around  the  field  and 
has  not  been  worked  out  in  detail. 

On  field  exit.,  if  we  assume  that  the  vehicle(s)  can  detect  the  exit, 
the  above  actions  can  be  cancelled  (perhaps  involving  another  brief  delay). 
If  the  exit  is  not  detectable,  then  concentric  ellipses  could  be  used  to 
delay  the  change  back  to  a  normal  condition  until  after  the  field  has  been 
left. 
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4.  Mine  Detonation 


When  a  vehicle  enters  a  minefield,  the  field  boundary  action 
is  responsible  for  planning  a  mine  detonation  and  storing  this  as  the 
internal  action  for  the  vehicle.  The  distance  that  the  vehicle  will  move 
before  detonating  a  mine  can  be  determined  using  a  random  draw  from  a 
distribution  whose  parameters  are  influenced  by 

a)  minefield  density 

b)  vehicle  geometry  (e.g.  track  width) 

c)  mine  detectability 

d)  whether  vehicle  is  in  a  cleared  path 

(e.g.  following  a  vehicle  with  a  plow) 

This  distance  is  used  for  the  vehicle's  FLD.INT.DIST  attribute.  If  the 
vehicle  travels  this  far  through  the  field  before  encountering  the  exit 
boundary,  then  a  field  internal  action  is  triggered.  This  action  should 
assess  the  lethality  of  the  mine,  and,  if  the  vehicle  can  still  move,  should 
plan  the  next  detonation. 

As  discussed  in  3)  above,  if  the  minefield  is  not  detectable,  then 
the  first  detonation  in  a  platoon  or  company  might  trigger  responses  from 
all  vehicles  in  that  unit. 

5.  Call  for  Artillery  or  Air  Strike 

One  possible  use  for  field  ellipses  is  to  represent  pre-planned 
artillery  or  close  air  support  trigger  areas.  The  presence  of  a  threshold 
number  of  enemy  vehicles  in  the  area  can  be  used  to  initiate  requests  for 
artillery  or  air  missions.  Implementing  this  concept  using  fields  calls  for 
establishing  a  counter  for  each  such  field  to  keep  track  of  the  number  of 
enemy  inside  the  field.  On  field  entry,  the  counter  is  incremented,  and 
perhaps  a  mission  request  is  initiated.  On  field  exit  the  counter  is 
decremented.  33 


Other  possible  uses  for  the  Field  module  will  no  doubt  become 
apparent  in  the  future.  Because  of  the  great  variety  of  possible  combin¬ 
ations  of  the  various  actions,  actual  implementation  of  the  actions  must 
await  guidance. 
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